In typical microcontroller devices, reset schemes are implemented whereby the microcontroller device will be reset upon a particular event occurring. In more intelligent systems, such a reset scheme may be divided into separate levels of reset, such as a destructive reset level and one or more functional reset levels. In a functional reset case only certain elements of the microcontroller device are reset, whilst in a destructive reset case a complete reset of the entire microcontroller device is performed. Accordingly, such a functional reset may typically be applied in response to non-critical reset events, whilst a destructive reset may be applied in response to a critical reset event. The limitation with conventional implementations is that reset events will always initiate a reset sequence ending in the device coming out of reset, even if the root cause of the reset has not been corrected by the reset sequence. However, in some cases it may be preferred to keep the device in a reset state in order to prevent reset cycling, in particular following a destructive reset.
For example, some non-critical events, such as a recurring system software watchdog timeout, may be handled as a destructive reset. If the root cause of the reset is not corrected by the reset sequence, this can lead to what is known as reset cycling (i.e. the device goes through a reset sequence, and the same or related reset event occurs again, thereby causing a new reset sequence to start). If such cycling continues it can lead to the situation where the error indicating event causing the reset spuriously does not occur, and the device starts to run in an inherently unsafe state since the root cause of the error will still be present. Furthermore, such reset cycling can also lead to increased power consumption.